Key-Value Storage System including a Resource-Efficient Index

ABSTRACT

A key-value storage system is described herein for interacting with key-value entries in a content store using a resource-efficient index. The index provides a data structure that includes a plurality of hash buckets. Each hash bucket includes a linked list of hash bucket units. The key-value storage system stores hash entries in each linked list of hash bucket units in a distributed manner between an in-memory index store and a secondary index store, based on time of their creation. The key-value storage system is further configured to store hash entries in a particular collection of linked hash bucket units in a chronological order to reflect time of their creation. The index further includes various tunable parameters that affect the performance of the key-value storage system.

BACKGROUND

A key-value storage system uses an index to access information in acontent store. For instance, the key-value storage system uses the indexto map a given key to a location of a corresponding value in the contentstore. Commonly, an index performs this mapping operation using anin-memory hash table. It is nevertheless a challenging task to providean in-memory index that provides satisfactory performance in aresource-efficient manner.

SUMMARY

A key-value storage system is described herein for using aresource-efficient index to interact with key-value entries in a contentstore. Overall, the index enables the key-value storage system to offergood performance from the standpoint of memory usage, speed ofoperation, and processor load.

According to one illustrative aspect, the index provides a datastructure that includes a plurality of hash buckets. Each hash bucketincludes a linked list of hash bucket units. Each hash bucket unit, inturn, includes a set membership filter (e.g., a bloom filter) and a hashblock. The hash block stores a collection of hash entries. The setmembership filter provides a mechanism for testing whether acorresponding hash block may contain a particular hash entry beingsought.

According to another illustrative aspect, each hash entry in a hashblock includes a partial key. The partial key has reduced size comparedto a full counterpart key provided in the content store.

According to another illustrative aspect, the key-value storage systemstores the hash blocks associated with a hash bucket in a distributedmanner between an in-memory index store and a secondary index store,such as, but not limited to, a disk-based secondary index store.

According to another illustrative aspect, the key-value storage systemis configured to store hash entries in a particular collection of linkedhash bucket units in a generally chronological order, e.g., by storingeach new hash entry in a head hash bucket unit of the particularcollection, and creating a new head hash bucket unit when a previoushead hash bucket unit cannot accommodate the new hash entry.

According to another illustrative aspect, the key-value storage systemdoes not include a sorting function for use in sorting key values. Forthis reason, the key-value storage system can eliminate the processingburden associated with a sorting function.

According to another illustrative aspect, the index further includesvarious tunable parameters (described herein) that affect theperformance of the key-value storage system. A developer may tune thevalues of the parameters to balance memory consumption, system speed andprocessor load, to achieve a desired overall level of performance.

According to another illustrative aspect, the key-value storage systemincludes a mechanism for updating the index in response to a garbagecollection process. The mechanism provides a service which is agnosticwith respect to the particular nature of the garbage collection process.

According to another illustrative aspect, the key-value storage systemprovides a way of preserving (and later accessing) plural versions ofeach key-value entry in the content store.

The above-summarized functionality can be manifested in various types ofsystems, devices, components, methods, computer-readable storage media,data structures, graphical user interface presentations, articles ofmanufacture, and so on.

This Summary is provided to introduce a selection of concepts in asimplified form; these concepts are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an overview of a key-value storage system that uses aresource-efficient index.

FIG. 2 shows a portion of a data structure used by the index. FIG. 2also shows a relationship of the data structure to key-value entriesstored in a content store.

FIG. 3 shows one way in which the key-value storage system candistribute hash entries between an in-memory index store and a secondaryindex store.

FIG. 4 shows functionality for computing various key-related values, foruse in the key-value storage system of FIG. 1.

FIG. 5 shows computer-related equipment for implementing the key-valuestorage system of FIG. 1, according to one implementation.

FIGS. 6 and 7 together show a process for adding a new key-value entryto the key-value storage system of FIG. 1.

FIG. 8 shows one manner of using the index to preserve the respectivelocations of different versions of a key-value entry, the differentversions being associated with a same key.

FIGS. 9-11 together show a process for querying a key of a sought-afterkey-value entry using the key-value storage system of FIG. 1.

FIG. 12 shows a process for updating the index of FIG. 1 to account fora garbage collection process.

FIG. 13 shows an outcome of the process of FIG. 12 for a key-value entrythat has been moved within the content store due the garbage collectionprocess.

FIG. 14 shows an outcome of the process of FIG. 12 for a key-value entrythat has been evicted from the content store due to the garbagecollection process.

FIG. 15 shows illustrative computing functionality that can be used toimplement any aspect of the features shown in the foregoing drawings.

The same numbers are used throughout the disclosure and figures toreference like components and features. Series 100 numbers refer tofeatures originally found in FIG. 1, series 200 numbers refer tofeatures originally found in FIG. 2, series 300 numbers refer tofeatures originally found in FIG. 3, and so on.

DETAILED DESCRIPTION

This disclosure is organized as follows. Section A describes acomputer-implemented system for interacting with key-value entries usinga resource-efficient index. Section B sets forth illustrative methodswhich explain the operation of the system of Section A. And Section Cdescribes illustrative computing functionality that can be used toimplement any aspect of the features described in Sections A and B.

As a preliminary matter, some of the figures describe concepts in thecontext of one or more structural components, also referred to asfunctionality, modules, features, elements, etc. In one implementation,the various components shown in the figures can be implemented bysoftware running on computer equipment, or hardware (e.g.,chip-implemented logic functionality), etc., or any combination thereof.In one case, the illustrated separation of various components in thefigures into distinct units may reflect the use of correspondingdistinct physical and tangible components in an actual implementation.Alternatively, or in addition, any single component illustrated in thefigures may be implemented by plural actual physical components.Alternatively, or in addition, the depiction of any two or more separatecomponents in the figures may reflect different functions performed by asingle actual physical component. Section C provides additional detailsregarding one illustrative physical implementation of the functionsshown in the figures.

Other figures describe the concepts in flowchart form. In this form,certain operations are described as constituting distinct blocksperformed in a certain order. Such implementations are illustrative andnon-limiting. Certain blocks described herein can be grouped togetherand performed in a single operation, certain blocks can be broken apartinto plural component blocks, and certain blocks can be performed in anorder that differs from that which is illustrated herein (including aparallel manner of performing the blocks). In one implementation, theblocks shown in the flowcharts can be implemented by software running oncomputer equipment, or hardware (e.g., chip-implemented logicfunctionality), etc., or any combination thereof.

As to terminology, the phrase “configured to” encompasses variousphysical and tangible mechanisms for performing an identified operation.The mechanisms can be configured to perform an operation using, forinstance, software running on computer equipment, hardware (e.g.,chip-implemented logic functionality), etc., or any combination thereof.

The term “logic” encompasses various physical and tangible mechanismsfor performing a task. For instance, each operation illustrated in theflowcharts corresponds to a logic component for performing thatoperation. An operation can be performed using, for instance, softwarerunning on computer equipment, hardware (e.g., chip-implemented logicfunctionality), etc., or any combination thereof. When implemented bycomputing equipment, a logic component represents an electricalcomponent that is a physical part of the computing system, in whatevermanner implemented.

Any of the storage resources described herein, or any combination of thestorage resources, may be regarded as a computer-readable medium. Inmany cases, a computer-readable medium represents some form of physicaland tangible entity. The term computer-readable medium also encompassespropagated signals, e.g., transmitted or received via a physical conduitand/or air or other wireless medium, etc. However, the specific terms“computer-readable storage medium” and “computer-readable storage mediumdevice” expressly exclude propagated signals per se, while including allother forms of computer-readable media.

The following explanation may identify one or more features as“optional.” This type of statement is not to be interpreted as anexhaustive indication of features that may be considered optional; thatis, other features can be considered as optional, although notexplicitly identified in the text. Further, any description of a singleentity is not intended to preclude the use of plural such entities;similarly, a description of plural entities is not intended to precludethe use of a single entity. Further, while the description may explaincertain features as alternative ways of carrying out identifiedfunctions or implementing identified mechanisms, the features can alsobe combined together in any combination. Finally, the terms “exemplary”or “illustrative” refer to one implementation among potentially manyimplementations.

A. Illustrative System

As noted above, a key-value storage system uses an in-memory index tomap a given key to a location of a corresponding value in a contentstore. Such a technique, however, can consume a significant amount ofmemory, particularly in the case in which there are a large number ofkeys to contend with and/or when the sizes of the keys are large. Somekey-value storage systems address the above-noted challenge using theB-tree technique. But the B-tree technique requires processingoperations (such as sorting) that place a significant processing burdenon the key-value storage system.

FIG. 1 shows a key-value storage system 102 that addresses at least theabove-noted technical challenge. The key-value storage system 102includes a store interaction component 104, a content store 106, and anindex 108. The store interaction component 104 interacts with thecontent store 106 using the index 108.

The content store 106 stores a plurality of key-value entries. Eachkey-value entry, in turn, specifies at least a full key and anassociated value. The value provides content associated with thekey-value entry. The key corresponds to an identifier associated withthe value. For example, consider the merely illustrative case in whichthe content store 106 stores information regarding a collection ofwebsites. In that context, each key may correspond to the URL associatedwith a particular website. The value may correspond to the websitecontents associated with the particular website. Consider another casein which the content store 106 provides credit history informationregarding a plurality of customers. In that context, each key maycorrespond to an ID associated with a corresponding customer. The valuemay correspond to that customer's credit history.

The content store 106 can be implemented using one or more physical datastores 110. For example, the content store 106 can be implemented usinga hard disk storage mechanism, a solid-state storage mechanism, etc., orany combination thereof.

The index 108 stores, among other information, a plurality of hashentries. Each hash entry, in turn, can specify at least a partial key,an address value, size information, etc. A partial key corresponds to areduced-size version of a corresponding full key. For example, thepartial key may represent a 27 bit version of a counterpart full 128 bitkey. The following description (with reference to FIG. 4) will providefurther details on different ways of computing the partial key. Withoutlimitation, in one approach, the key-value storage system 102 computesthe partial key by taking a portion of a full key (e.g., by taking onehalf of a 128 bit full key), hashing that portion to generate a hashresult, and then truncating that hash result to a desired size (e.g., to27 bit). The address value specifies a location at which a correspondingkey-value entry is stored in the content store 106. The size informationspecifies the size of the key-value entry stored in the content store106.

The index 108 can be implemented using two or more physical data stores112. For example, the key-value store 106 can be implemented using anin-memory index store (also referred to as a “memory index store”)together with a secondary index store. The secondary index store maycorrespond to a hard disk storage mechanism, a solid-state storagemechanism, etc., or any combination thereof. Information in thein-memory index store is more readily accessible to the storeinteraction component 104 compared to the secondary index store.

In one implementation, the secondary index store (associated with theindex 108) is implemented by at least part of the same physical datastore associated with the content store 106. In another implementation,the secondary index store and the content store 106 are implemented bytwo separate physical data stores.

The store interaction component 104 includes (or can be conceptualizedas including) plural subcomponents that perform different respectivefunctions. An insertion component 114 inserts new key-value entries inthe content store 106, and adds counterpart new hash entries in theindex 108. A query component 116 retrieves a key-value entry from thecontent store 106 using the index 108. That is, given a specified fullkey, the query component 116 uses the index 108 to retrieve a key-valueentry from the content store 106 that is associated with the given fullkey. A relocation and eviction (R&E) component 118 updates the index 108in response to a garbage collection process performed by garbagecollection functionality 120. For instance, the R&E component 118accounts for the movement of key-value entries from old locations to newlocations within the content store 106. The R&E component 118 alsoaccounts for the eviction of key-value entries from the content store106. Section B sets forth processes which describe the illustrativeoperation of the insertion component 114, the query component 116 andthe R&E component 118.

FIG. 1 also shows one data structure 122 for use in organizinginformation within the index 108. The data structure 122 includes aplurality of hash buckets 124. In one non-limiting and illustrativecase, the data structure 122 includes 1024 hash buckets for storing 10GB of data. The data structure 122 also includes a bucket index 126 formapping a hashed version of a specified full key to one of the hashbuckets 124. The hashed version of the specified full key is referred toherein as a hash bucket identifier.

Each hash bucket includes a plurality of linked hash bucket units, suchas, without limitation, a maximum number of 20 hash bucket units. In oneimplementation, the plurality of linked hash bucket units can be formedas a linked list of hash bucket units. A head hash bucket unitcorresponds to a first hash bucket unit in a linked list. The head hashbucket unit is linked to a second hash bucket unit in the linked list.The second hash bucket unit is linked to the third hash bucket unit inthe linked list, and so on. The bucket index 126 includes pointers whichmap to the respective head hash bucket units.

FIG. 2 shows the illustrative composition of two hash bucket units (202,204) in a linked list of hash bucket units. The composition of theillustrative hash bucket unit 202 is explained below. Other hash bucketunits, such as the hash bucket unit 204, have the same composition asthe hash bucket unit 202.

The hash bucket unit 202 includes a bloom filter 206. At any given time,the bloom filter 206 represents a set of one or more bloom filter keys,e.g., by storing a set of bloom filter entries derived from the bloomfilter keys. Each bloom filter key (and a corresponding bloom filterentry), in turn, is derived from a corresponding full key in a mannerthat will be described below (with reference to FIG. 4). In operation,the query component 116 can query the bloom filter 206 to determinewhether a specified bloom filter key is included within its set of bloomfilter keys. If this query is answered in the affirmative, the querycomponent 116 can conclude that the hash bucket unit 202 may include ahash entry being sought, subject to the possibility of a false positive.If this query is answered in the negative, the query component 116 canconclusively determine that the hash bucket unit 202 does not containthe hash entry being sought.

In other words, the bloom filter 206 may produce a false positive, butcannot produce a false negative. A false positive occurs when the bloomfilter 206 indicates that a specified bloom filter key is a member ofits set, but, in fact, the bloom filter key is not a member of the set.A false negative (which cannot occur) corresponds to the case in whichthe bloom filter 206 indicates that a specified bloom filter key is nota member of its set, when it is, in fact, actually a member. Theindividual bloom filter 206 produces false positives at a specifiedrate, which is typically very low.

The hash bucket unit 202 further includes a link 208 to a nextsuccessive hash bucket unit, in this case, corresponding to hash bucketunit 204. The hash bucket unit 202 further includes a pointer 210 to alocation of a hash block 212 in the secondary index store. In operation,the query component 116 can first query the bloom filter 206 todetermine whether a given bloom filter key is included within the bloomfilter's set of encoded bloom filter keys. This matching outcome alsoconveys whether a hash entry being sought is included within the hashblock 212. Upon a matching result, the query component 116 thendetermines whether the hash bucket unit 202 currently stores the hashblock 212 in its in-memory (primary) index store. If not, the querycomponent 116 can use the pointer 210 to retrieve the hash block 212from the secondary index store and store it in the in-memory indexstore.

The above-described distributed manner of storing hash blocks is onefactor which helps reduce the memory requirements of the key-valuestorage system 102. For instance, the index 108 can selectively retrievea hash block from the secondary index store only when it is determined(by a corresponding bloom filter) that the hash block may contain a hashentry being sought. For each bloom filter that provides a negativematching result within a hash bucket, there is no need to store itscorresponding hash block in the in-memory (primary) index store.

The hash block 212 itself includes a plurality of hash entries, such as,in one non-limiting implementation, 512 hash entries. The key-valuestorage system 102 employs a plurality of hash entries to facilitatestorage and retrieval of the hash entries from the secondary indexstore, as opposed to storing and retrieving hash entries on anindividual basis. Each hash entry includes at least a partial key, anaddress value, and size information. As noted above, the partial key cancorrespond to a hashed portion of the full key. The use of partial keys(instead of counterpart full keys) in the index 108 further reduces theamount of memory used by the index 108. The address value specifies alocation where a corresponding key-value entry is stored in the contentstore 106. For instance, consider a particular hash entry 214. That hashentry 214 includes an address value which points to the location of akey-value entry 216 in the content store 106. The size informationdescribes the size of a corresponding key-value entry in the contentstore 106.

Although not explicitly shown in FIG. 2, each hash bucket unit can alsostore a bloom key block that provides the original bloom filter keysthat were used to generate the bloom filter entries in the unit's bloomfilter. The key-value storage system 102 relies on the bloom filter keysstored in the bloom key blocks during the below-described garbagecollection process. More specifically, the key-value storage system 102relies on the bloom filter keys to reconstruct the bloom filters in theindex 108 in response to the movement and deletion of entries in thecontent store 106, and corresponding changes made to the index 108. Thehash blocks cannot be relied on to reconstruct the bloom filters becausethey do not store the portions of the full keys that were used toconstruct the bloom filters. In other implementations, the bloom filterkeys can be stored in other locations and/or data structures within thekey-value storage system 102.

FIG. 3 shows one manner by which the key-value storage system 102 ofFIG. 1 distributes hash blocks between an in-memory (primary) indexstore 302 and a secondary index store 304. Recall that the secondaryindex store 304 may correspond to a hard disk storage mechanism, asolid-state storage mechanism, etc., or combination thereof. FIG. 3particularly depicts the composition of one illustrative hash bucket306. Other hash buckets, although only depicted in summary form in FIG.3, have a similar composition.

The illustrative hash bucket 306 includes a linked list of hash bucketunits. That is, the hash bucket 306 includes a first (head) hash bucketunit 308, a second hash bucket unit 310, a third hash bucket unit 312,and so on. The head hash bucket unit 308 includes an in-memory headbloom filter 314 and an in-memory head hash block 316. Likewise, thesecond hash bucket unit 310 includes an in-memory bloom filter 318 andan in-memory hash block 320. But at the present time, the third hashbucket unit 312 stores just a bloom filter 322 in the in-memory indexstore 302; the third hash bucket unit 312 stores its corresponding hashblock 324 in the secondary index store 304 (not, at this time, in thein-memory index store 302). Remaining hash bucket units have the sameconfiguration as the third hash bucket unit 312.

More specifically, in one implementation, the insertion component 114(of FIG. 1) adds each new hash entries to the head hash bucket unit 308until its corresponding head hash block 316 is full and cannotaccommodate the storage of additional hash entries. Upon an indicationthat the head hash block 316 is full, the insertion component 114creates a new hash bucket unit and adds that new hash bucket unit to thebeginning of the linked list of hash bucket units. In other words, thisnew hash bucket unit assumes the role of a new head hash bucket unithaving an associated new head hash block. As a result, the key-valuestorage system 102 can be said to store new hash entries across a hashbucket's hash blocks in a generally chronological order based on theorder in which they were inserted into the index 108. For instance, hashentries in a hash bucket unit near the tail of the linked listcorrespond to older entries compared to hash entries in a hash bucketunit near the head of the linked list.

As will be explained in greater detail in Section B, a linked list canalso store hash entries that represent different versions of a key-valueentry, associated with a same key. A hash entry that represents acurrent version of the key-value entry will occur closer to the head ofthe linked list compared to hash entry representing an older version ofthe key-value entry.

The key-value storage system 102 manages each hash bucket such that, atany given time, at least n of its most recently created hash bucketunits have their respective hash blocks stored in the in-memory indexstore 302. The remainder of the hash bucket units has their respectivehash blocks stored in the secondary index store 304. Without limitation,in the example of FIG. 3, n=2 because hash bucket unit 308 and hashbucket unit 310 have their respective hash blocks (316, 320) stored inthe in-memory index store 302. As noted above, this storage strategyhelps reduce the amount of memory required by the key-value storagesystem 102 at any given time.

The key-value storage system 102 stores the n most recently created hashblocks in the in-memory index store 302 because there is an increasedpossibility that the store interaction component 104 will be interactingwith these hash blocks, as opposed to older hash blocks. For example,the key-value storage system 102 stores the head hash block 316 in thein-memory index store 302 because the key-value storage system 102 willrepeatedly interact with the head hash block 316 by adding new hashentries to it, until it is full.

The store interaction component 104 can also temporally move any hashblock from the secondary index store 304 to the in-memory index store302 when the query component 116 seeks to interact with it. For example,assume that the query component 116 seeks to find a key-value entrycorresponding to a specified full key. As will be described more fullyin Section B, the query component 116 can first determine the hashbucket to which the full key corresponds. Assume that it corresponds tothe hash bucket 306 of FIG. 3. The query component 116 can thensuccessively test each bloom filter of each respective hash bucket unit,starting with the head hash bucket unit 308, until it finds a match (ifany). Assume that the query component 116 determines that a bloom filter326 of a nineteenth hash bucket unit 328 provides a match, indicatingthat its corresponding hash block 330 may store a hash entry beingsought, subject to a small false positive probability. At this juncture,the store interaction component 104 can retrieve the hash block 330 fromthe secondary index store 304 and store it in the in-memory index store302. The query component 116 then proceeds to process the hash entriesin the hash block 330 to determine if the hash entry being sought isincluded within the hash block 330.

The store interaction component 104 can use different strategies fordetermining how long a queried hash block will remain in the in-memoryindex store 302. In one case, the store interaction component 104 marksan in-memory hash block to be discarded immediately after a query hasbeen completed. In another case, the store interaction component 104marks an in-memory hash block for removal a prescribed amount of timeafter a query has been completed. This latter strategy may beappropriate in those application-specific environments in which there isa heightened probability that the query component 116 will soon makeanother query directed to the same hash block. The same is true withrespect to a former head hash block; the storage interaction component104 can immediately discard the former head hash block from thein-memory index store 302 when a new head hash block has been created,or some configurable time thereafter.

FIG. 4 shows functionality for computing various key-related values thatare used by the key-value storage system 102 of FIG. 1. In one case, thestore interaction component 104 can implement the functionality as alibrary of common resource components. The insertion component 114,query component 116, and R&E component 118 can rely on these resourcecomponents in performing their respective operations.

As a first operation, a decomposition component 402 can split a full key404 under consideration into to two parts, corresponding to an initialpartial key 406 and a bloom filter key 408. For example, assume that thefull key 404 includes x units of information (e.g., x bits). Thedecomposition component 402 can use the first half of those units ofinformation to create the initial partial key 406, and the second halfof those units of information to create the bloom filter key 408.

A first computation component 410 uses a hash function to hash the fullkey 404 to produce a hash bucket identifier. The hash function can beimplemented using any algorithm, such as a cyclic redundancy check (CRC)algorithm, any kind of cryptographic hash algorithm (e.g., MD5, SHA-1),etc.

A second computation component 412 can optionally use any hash functionto hash the initial partial key 406 to produce a hash result. Inaddition, the second computation component 412 can truncate the hashresult to correspond to a particular size, to produce a final partialkey. The final partial key has a reduced size (e.g., having a size of 27bits) compared to the full key 404 (e.g., having a size of 128 bits).Other implementations can produce the final partial key in alternativeways. For example, another implementation can use the initial partialkey as the final partial key, without modification. Hence, as usedherein, the term “partial key” represents any item of information thatis derived from the full key 404 in any manner, and which has a smallersize compared to the full key 404.

A third computation component 414 uses a set of k independent hashfunctions to hash the bloom filter key 408 to produce a bloom filterentry. Each of the k hash functions maps the bloom filter key 408 to aparticular cell location within a set of m cell locations within thebloom filter 206.

More specifically, the third computation component 414 can work incooperation with both the insertion component 114 and the querycomponent 116. In a first scenario, assume that the insertion component114 invokes the third computation component 414 to add a new bloomfilter entry to the bloom filter 206. Here, the third computationcomponent 414 applies the k hash functions to the bloom filter key 408to determine a set of k cell locations in the bloom filter 206, and thensets the values of those cells to 1 (presuming that, by default, eachcell value is initially set to 0 until it is modified).

In a second scenario, assume that the query component 116 invokes thethird computation component 414 to determine whether the bloom filter206 already represents the particular bloom filter key 408. Here, thethird computation component 414 applies the k hash functions to thebloom filter key 408 to determine a set of k cells in the bloom filter206. The third computation component 414 then determines whether each ofthose k cells has a value of 1. If at least one of the k cells has azero value, then the query component 116 conclusively determines thatthe bloom filter 206 does not match the bloom filter key 408 (meaningthere is no possibility of a false negative). If all of the k cells havethe value of 1, then the query component 116 determines that the bloomfilter 206 matches the bloom filter key 408, subject to a prescribedprobability that a false positive has occurred (which is typically verylow).

Note that the data structure 122 can use other types of set membershipfilters besides a bloom filter. In general, a set membership filterrepresents a set of set membership keys in any manner. It furtherprovides a way of determining whether a specified set membership key isincluded within the set. Alternative set membership techniques (besidesa bloom filter technique) include, without limitation, dictionary-basedtechniques, hash compaction techniques, cuckoo filter techniques (whichinvolves the use of cuckoo hashing), etc.

More generally, note that the functionality of FIG. 4 computes the finalpartial key and the bloom filter entry based on the same full key 404.But the second computation component 412 and the third computationcomponent 414 perform their respective operations (e.g., theirrespective hashing operations) in an independent manner.

FIG. 5 shows computer equipment for implementing the key-value storagesystem 102 of FIG. 1, according to one implementation. In this case,remote computing functionality 502 provides a network-accessiblestorage-related service (e.g., a cloud storage service). Thestorage-related service can include all of the features shown in FIG. 1,including the store interaction component 104 and the data stores (110,112) used to implement the content store 106 and the index 108. From aphysical perspective, the remote computing functionality 502 can beimplemented using one or more server computing devices and any othercomputer-related equipment (e.g., routers, etc.).

Any client computing functionality 504 can interact with the remotecomputing functionality 502 via a communication conduit 506. In onescenario, the client computing functionality 504 can correspond to auser computing device of any type. A user may interact with the remotecomputing functionality 502 using the client computing functionality 504to store information, retrieve information, etc. In another scenario,the client computing functionality 504 can correspond to some servercomputing device (or devices) associated with any type of system. Forexample, the client computing functionality 504 can correspond toanother network-accessible service that performs a process that, as partthereof, involves interaction with the storage service provided by theremote computing functionality 502. The communication conduit 506 cancorrespond to a wide area network (e.g., the Internet), a local areanetwork, a peer-to-peer network of any type, one or more point-to-pointlinks, etc.

In another implementation, at least some of the features of thekey-value storage system 102 can be distributed between remote computingfunctionality 502 and the client computing functionality 504 in anymanner. In another implementation, the client computing functionality504 implements a separate instance of all of the functionalityassociated with the key-value storage system 102, thereby entirelyeliminating the use of the remote computing functionality 502.

B. Illustrative Processes

FIGS. 6-7 and 9-12 show processes that explain the operation ofkey-value storage system 102 of Section A in flowchart form. Since theprinciples underlying the operation of the key-value storage system 102have already been described in Section A, certain operations will beaddressed in summary fashion in this section. As noted in the prefatorypart of the Detailed Description, the flowchart is expressed as a seriesof operations performed in a particular order. But the order of theseoperations is merely representative, and can be varied in any manner.

FIGS. 6 and 7 together show a process 602 for adding a new key-valueentry to the key-value storage system 102 of FIG. 1. In block 604, theinsertion component 114 receives a full key and a value associated withthe new key-value entry. In block 606, the insertion component 114stores the full key and value in the content store 106, to provide a newkey-value entry. In block 608, the insertion component 114 hashes thefull key to generate a hash bucket identifier. In block 610, theinsertion component 114 generates a partial key based on the full key.In block 612, the insertion component 114 generates a set membershipfilter entry (e.g., a bloom filter entry) based on the full key. SectionA, with reference to FIG. 4, explained illustrative techniques forperforming blocks 608-612. In block 614, the insertion component 114identifies a matching hash bucket (if any) based on the hash bucketidentifier computed in block 608.

Advancing to FIG. 7, in block 702, the insertion component 114determines whether an existing head hash block, included within a headhash bucket unit in the matching hash bucket, is full. In block 704, theinsertion component 114 creates a new head hash bucket unit, having anew set membership filter and a new hash block, if the existing headhash bock is full. In block 706, the insertion component 114 adds theset membership filter entry (computed in block 612) to the setmembership filter of the new head hash bucket unit (if it has beencreated), else the insertion component 114 adds it to the existing headhash bucket unit. In block 708, the insertion component 114 stores a newhash entry to the new head hash block (if it has been created), else theinsertion component 114 stores it in the existing head hash block. Thenew hash entry includes at least the partial key (computed in block 610)and an address value at which the new key-value entry is stored in thecontent store 106.

FIG. 8 illustrates how the process 602 of FIG. 6 operates to adddifferent hash entries in a hash bucket, corresponding to differentrespective versions of a key-value entry provided in the content store106. Each hash entry, corresponding to a different version of thekey-value entry, is associated with a same key, e.g., key X.

More specifically, assume that the insertion component 114 stores afirst hash entry 802 corresponding to a first version of the key-valueentry in a hash bucket unit 804. The first hash entry 802 includes anaddress value which points to the location of the first version of thekey-value entry in the content store 106. At the time of the insertionof the first hash entry 802, assume that the hash bucket unit 804represented the head hash bucket unit of the linked list. But at thepresent time, assume that the hash bucket unit 804 is no longer the headhash bucket unit because subsequent hash bucket units have been added tothe beginning of the linked list, after the insertion of the first hashentry 802.

In a more recent operation, assume that the insertion component 114stores a second hash entry 806 (corresponding to a second version of thekey-value entry) in a hash bucket unit 808. The hash bucket unit 808represents the head hash bucket unit at a current time. The second hashentry 806 includes an address value which points to the location of thesecond version of the key-value entry in the content store 106. In thiscase, the insertion component 114 adds the second hash entry 806 to thehash bucket unit 808 because that hash bucket unit is the head of thelinked list (and because all new hash entries are stored in the headhash bucket unit, even those corresponding to revisions of a previouslystored key-value entry).

Overall, observe that any linked list of hash bucket units reveals theapproximate timing at which revisions were made to a key-value entrybased on the locations of the corresponding hash entries in the linkedlist. As described below, the store interaction component 104 can alsoleverage the above-described manner of storing different versions byselectively retrieving a desired version of a key-value entry from thecontent store 106.

The insertion component 114 can also use the process 602 of FIGS. 6 and7 to delete an entry from the content store 106, and to make acorresponding update to the index 108. To do so, the insertion component114 adds a new key-value entry to the content store 106 that has thecorrect key as the entry being deleted, but with an empty value(corresponding to any value associated by definition with an emptyresult). The insertion component 114 updates the index 108 in the samemanner described above to reflect the new version of key-value entrythat has been added to the content store 106.

FIGS. 9-11 together show a process 902 for querying a key of asought-after key-value entry using the key-value storage system 102 ofFIG. 1. In block 904, the query component 116 receives a full keyassociated with the sought-after key-value entry. In block 906, thequery component 116 hashes the full key to generate a hash bucketidentifier. In block 908, the query component 116 generates a partialkey based on the full key. In block 910, the query component 116generates a set membership filter entry (e.g., a bloom filter entry)based on the full key. Again, Section A (with reference to FIG. 4)describes one technique for performing operations 906-910.

Advancing to FIG. 10, in block 1002, the query component 116 identifiesa matching hash bucket based on the hash bucket identifier. In block1004, the query component 116 identifies a matching hash bucket unit bycomparing the set membership filter entry (computed in block 910) toeach set membership filter in the matching hash bucket until a match isfound, if any. The matching hash bucket includes an associated matchinghash block.

In block 1006, the query component 116 determines whether the matchinghash block is provided in the in-memory index store 302. In block 1008,the query component 116 retrieves the matching hash block from thesecondary index store 304 and stores the matching hash block in thein-memory index store 302 if it is not already in the in-memory indexstore 302. In block 1010, the query component 116 identifies a matchinghash entry, if any, in the matching hash block, by comparing the partialkey (computed in block 908) of the sought-after key-value entry witheach hash entry in the matching hash block.

There is a chance that the matching hash block does not including amatching hash entry, e.g., because the corresponding set membershipfilter is subject to false positives. If block 1010 terminates in afailure to find the matching hash entry, then the process flow returnsto block 1004, where the query component 116 moves on to examine thenext hash bucket unit. If the last hash bucket unit is reached withoutencountering a matching hash entry, then the process 902 terminates withan indication that the sought-after key-value entry could not be found.But assume in this example that block 1010 successfully identifies amatching hash entry.

Advancing to FIG. 11, in block 1102, the query component 116 retrieves akey-value entry from the content store 106 that matches an address valuespecified by the matching hash entry (identified in block 1010), toprovide a retrieved key-value entry. In block 1104, the query component116 determines whether a full key associated with the retrievedkey-value entry matches a full key associated with the sought-afterkey-value entry, as provided in block 904. In block 1106, the querycomponent 116 continues a search within the index if the full key of theretrieved key-value entry does not match the full key associated withthe sought-after key-value entry. That is, the query component 116continues the search by returning to block 1010.

The query component 116 can implement the continued search operation indifferent ways. Assume that the query component 116 determines that amatching hash entry leads to a collision, meaning that it points to somekey-value entry in the content store 106 other than the sought-afterkey-value entry. The query component 116 can flag the matching hashentry as being invalid, e.g., by storing its address value in an invalidentry store, indicating that this address value points to an incorrecthash-value entry. The query component 116 can then re-perform the searchoperation. Upon retry, the query component 116 will first encounter thesame previously-identified hash entry. The query component 116 can thenconsult the invalid entry store to determine that thepreviously-identified matching hash entry does not correspond to thecorrect sought-after key value entry. At this juncture, the querycomponent 116 continues its search within the matching hash bucket, pastthe previously-identified matching hash entry. That is, the querycomponent 116 will first continue the search by looking at hash entriesin the matching hash bucket unit past the previously-identified matchinghash entry. If another matching hash entry is not found, the querycomponent 116 will then advance to examine the hash entries associatedwith a next matching hash block (if any), and so on.

In some implementations, a garbage collection process (performed by thegarbage collection functionality 120 of FIG. 1) can operate on thecontent store 106 by deleting hash entries and moving hash entries tonew locations. As will be described below with reference to FIG. 12, theR&E component 118 can make complementary updates to the index 108. Thesegarbage collection operations pose a risk that the index 108 will nolonger contain an address value that has been previously flagged asbeing invalid. The query component 116 can address this situation byre-performing the search for a sought-after key-value entry from anew,that is, without any previous knowledge of any previously-identifiedmatching hash entry. The query component 116 can take this approachwhenever it learns that the R&E component 118 has modified the index 108such that previously identified invalid address values may no longerappear in the index 108, or if they do appear, may no longer point toinvalid key-value entries.

The query component 116 can also be configured to retrieve one or morespecific versions of a key-value entry. For example, assume there arethree version of a key-value entry stored in the content store 106,created at different respective times, and that there are threecorresponding hash entries in the index 108 for those three versions.Further assume that a caller wishes to retrieve the oldest version,e.g., corresponding to the first version. The query component 116 canretrieve the desired version by examining the hash blocks from newest tooldest in the above-described manner. In doing so, the query component116 will first encounter a matching hash entry associated with the third(and most recent) version. The query component 116 will ignore thisversion after verifying that it does indeed correspond to the correctthird version, e.g., by checking the counterpart full key in the contentstore 106. Upon continuing the search, the query component 116 will nextencounter a matching hash entry associated with the second version.Again, the query component 116 will ignore this matching hash entryafter verifying that it does indeed correspond to the correct secondversion. Upon continuing the search, the query component 116 willfinally encounter the matching hash entry associated with the desiredfirst version. The query component 116 will then retrieve the key-valueentry specified by the address value of the final matching hash entry,after verifying that this entry corresponds to the sought-afterkey-value entry.

In another scenario, a caller can request retrieval of any two or more(including all) versions of a key-value entry. The query component 116will perform the same operations as above, but in this case, the querycomponent 116 will retrieve plural key-value entries.

FIG. 12 shows a process 1202 for updating the index of FIG. 1 to accountfor a garbage collection process. The garbage collection functionality120 (of FIG. 1) can perform the garbage collection process on a periodicand/or event-driven basis to relocate at least some key-value entries inthe content store 106 and/or to evict at least some key-value entries inthe content store 106. The garbage collection functionality 120 performsthis task to get rid of deleted and overwritten key-value entries. Bydoing so, the garbage collection functionality 120 creates storage spacefor accommodating new key-value entries. The R&E component 118complements this garbage collection process by making appropriatechanges to the index 108 to account for changes made to the contentstore 106.

In block 1204, the R&E component 118 receives modification informationfrom the garbage collection functionality 120 with respect to at leastone modified key-value entry. The modified key-value entry correspondsto a particular key-value entry in the content store 106 that has beenmodified by the garbage collection functionality 120. The modificationinformation may include an old address value associated with theparticular key-value entry, a new address value associated with theparticular key-value entry, and a key associated with the particularkey-value entry. In block 1206, the R&E component 118 uses themodification information to find a matching hash entry in the index 108.In block 1208, the R&E component 118 updates the matching hash entrybased on the modification information.

The R&E component 118 performs block 1206 by using the specified key tofind a matching hash entry in the same manner described above withrespect to the process 902. In this case, however, the R&E component 118can verify that the matching hash entry is correct (and not the resultof a collision) by determining whether the address value associated withthe matching hash entry matches the old address value given by themodification information. This determination is conclusive, such thatthe R&E component 118 does not need to retrieve any information from thecontent store 106. If there is a mismatch between the old address valueand the address value associated with the matching hash entry, the R&Ecomponent 118 can continue its search for the next matching hash entry.

FIG. 13 shows an outcome of the process of FIG. 12 for a particularkey-value entry that has been moved within the content store 106. Morespecifically, assume that the garbage collection process moves aparticular key-value entry in the content store 106 from an old locationin the content store 106, associated with an old address value, to a newlocation in the content store 106, associated with a new address value.The R&E component 118 updates the matching hash entry 1302 by changingan address value 1304 specified by the matching hash entry 1302(associated with the old location) to the new address value associatedwith the new location. In other words, the R&E component 118 updates thematching hash entry 1302 in place within its hash block.

FIG. 14 shows an outcome of the process of FIG. 12 for a particularkey-value entry that has been evicted from the content store due to thegarbage collection process. In this case, the R&E component 118 sets thenew address value to an invalid value to indicate that the new addressvalue is invalid. An “invalid value” refers to any value that willsubsequently be interpreted as invalid by default. Further, the R&Ecomponent 118 updates a matching hash entry 1402 by changing an addressvalue 1404 specified by the matching hash entry 1402 to correspond tothe invalid value. In addition, the R&E component 118 can update apartial key 1406 of the matching hash entry 1402 to correspond to aninvalid value. By doing so, the R&E flags the matching hash entry 1402for subsequent removal by the R&E component 118.

The R&E component 118 (or some other process) can perform a subsequentcompaction or clean-up process to purge the index 108 of invalid hashentries. The R&E component 118 can perform this task on a periodic basisor an event-driven basis. In one approach, the R&E component 118 cancreate a new linked list of hash bucket units for each hash bucket. TheR&E component 118 can then copy over all the valid hash entries from thefirst version of the linked list to the new version of the linked list,omitting any invalid hash entries. The R&E component 118 also updatesthe bucket index 126 such that it includes pointers to the respectiveheads of the new linked lists.

Note that the R&E component 118 reacts to actions taken by the garbagecollection functionality 120, but is otherwise agnostic with respect to(and independent of) the nature of the garbage collection process thatis performed by the garbage collection functionality 120. In otherwords, the R&E component 118 can work with any garbage collectionprocess, so long as it is informed by the garbage collection process ofthe changes it has made to the key-value entries in the content store106.

As a final topic in this section, the key-value storage system 102 ofFIG. 2 includes various parameters that can be tuned to ensure desiredperformance. Performance is gauged from the standpoint of at leastmemory consumption, speed of operation, and processing load. Theparameters can include, but are not limited to: the number of hashbuckets; the maximum number of hash bucket units associated with eachhash bucket; the maximum number of hash entries per hash block; thenumber of hash blocks that are stored in the in-memory index store 302at any given time; the size of each partial key value; a false positiveprobability associated with each individual set membership filter; afalse positive probability associated with a hash bucket's entirecollection of set membership filters; a block collision probabilityassociated with the process of matching a partial key against hashentries within a particular hash block, etc.

With respect to the topic of false positive probability, afilter-specific false positive probability represents the chance thateach individual set membership filter will provide a false positiveresult. For a bloom filter, the filter-specific false positiveprobability approximately corresponds to (1−e^(−kn/m))^(k) where m isthe number of cell locations in the bloom filter 206, n is the number ofbloom keys represented by the bloom filter 206, and k is the number ofhash functions used to produce each bloom filter entry. The overallfalse positive probability corresponds to the binomial probability thatat least one of the bloom filters within a hash bucket will provide afalse positive result. According to one configuration, the key-valuestorage system 102 can ensure that no more than 1% of queries willproduce a false positive outcome by using a maximum of 20 hash bucketunits per hash bucket, together with a 1 KB bloom filter that representsa maximum of 512 bloom filter entries and has a filter-specific falsepositive probability of less than 0.05%.

The block collision probability refers to a chance that a given partialkey will produce at least one false match with respect to any hash entryin a hash block. The collision probability can be computed based on thefollowing formula:

${{collision}\mspace{14mu} {probability}} = {1 - {\left( {1 - \left( \frac{1}{2^{\alpha}} \right)} \right)^{\beta}.}}$

α corresponds to the size of a partial key. β corresponds to a number ofhash entries in a hash block. For example, for α=27 bits and β=512 hashentries, the block collision probability corresponds to false match rateof less than 0.05%.

Different parameters affect performance in different ways. For example,the size of the partial key and the number of hash blocks in memory atany given time influence the memory consumption of the key-value storagesystem 102. The overall false positive probability and the blockcollision probability influence the speed of operation of the key-valuestorage system 102 and the processor load imposed by the key-valuestorage system 102; this is because any instance of false matching slowsthe key value storage down and consumes processing cycles.

Moreover, note that a change that decreases the utilization of memory(which is desirable) can create undesirable changes to processing speedand processor load, and vice versa. For example, a developer maydecrease the size of each partial key, but doing so increases thecollision rate of the key-value storage system 102, which, in turn,slows down the operation of the key-value storage system 102. Adeveloper can choose a particular combination of parameter values toachieve a desired consumption of resources to suit the demands of aparticular environment.

Further note that the key-value storage system 102 described above doesnot involve sorting of keys, which is a common component of manyconventional key-value storage systems. Because of this, the key-valuestorage system 102 can eliminate the processing cycles that wouldotherwise go into the sorting operation. This results in an increase inprocessing speed and a decrease in processing load. But note that it isalso possible to combine the key-value storage system 102 withkey-sorting functionality. In other words, the key-value storage systemdoes not preclude a sorting operation, although it can operate at fasterspeeds without the sorting operation.

C. Representative Computing Functionality

FIG. 15 shows computing functionality 1502 that can be used to implementany aspect of the mechanisms set forth in the above-described figures.For instance, the type of computing functionality 1502 shown in FIG. 15can be used to implement any of the remote computing functionality 502(such as a server computing device), the client computing functionality504 of FIG. 5 (such as a user computing device), etc. Note, however,that the set of features described in FIG. 15 is illustrative, and thatany particular manifestation of the computing functionality 1502 canomit one or more of the features shown in FIG. 15, and/or add one ormore features that are not illustrated in FIG. 15. In all cases, thecomputing functionality 1502 represents one or more physical andtangible processing mechanisms.

The computing functionality 1502 can include one or more hardwareprocessor devices 1504, such as one or more central processing units(CPUs), and/or one or more graphical processing units (GPUs), and so on.The computing functionality 1502 can also include any storage resources(also referred to as computer-readable storage media orcomputer-readable storage medium devices) 1506 for storing any kind ofinformation, such as machine-readable instructions, settings, data, etc.Without limitation, for instance, the storage resources 1506 may includeany of RAM of any type(s), ROM of any type(s), flash devices, harddisks, optical disks, and so on. More generally, any storage resourcecan use any technology for storing information. Further, any storageresource may provide volatile or non-volatile retention of information.Further, any storage resource may represent a fixed or removablecomponent of the computing functionality 1502. The computingfunctionality 1502 may perform any of the functions described above whenthe hardware processor device(s) 1504 carry out computer-readableinstructions stored in any storage resource or combination of storageresources. For instance, the hardware processor device(s) 1504 can carryout computer-readable instructions to perform each of the processesdescribed in Section B. The computing functionality 1502 also optionallyincludes one or more drive mechanisms 1508 for interacting with anystorage resource, such as a hard disk drive mechanism, an optical diskdrive mechanism, and so on.

In some user computing device manifestations, the computingfunctionality 1502 also includes an input/output component 1510 forreceiving various inputs (via input devices 1512), and for providingvarious outputs (via output devices 1514). One particular outputmechanism may include a display device 1516 and an associated graphicaluser interface presentation (GUI) 1518. In some manifestations, thecomputing functionality 1502 can also include one or more networkinterfaces 1520 for exchanging data with other devices via one or morecommunication conduits 1522. One or more communication buses 1524communicatively couple the above-described components together.

The communication conduit(s) 1522 can be implemented in any manner,e.g., by a local area computer network, a wide area computer network(e.g., the Internet), point-to-point connections, etc., or anycombination thereof. The communication conduit(s) 1522 can include anycombination of hardwired links, wireless links, routers, gatewayfunctionality, name servers, etc., governed by any protocol orcombination of protocols.

Alternatively, or in addition, any of the functions described in thepreceding sections can be performed, at least in part, by one or morehardware logic components. For example, without limitation, thecomputing functionality 1502 (and its hardware processor) can beimplemented using one or more of: Field-programmable Gate Arrays(FPGAs); Application-specific Integrated Circuits (ASICs);Application-specific Standard Products (ASSPs); System-on-a-chip systems(SOCs); Complex Programmable Logic Devices (CPLDs), etc. In this case,the machine-executable instructions are embodied in the hardware logicitself.

The following summary provides a non-exhaustive list of illustrativeaspects of the technology set forth herein.

According to a first aspect, a key-value storage system, implemented byone or more computing devices, is described herein. The key-valuestorage system includes a content store for storing a plurality ofkey-value entries, each key-value entry providing a full key and anassociated value. The key-value storage system also includes an indexincluding an in-memory index store and a secondary index store, togetherwith a store interaction component configured to interact with thecontent store using the index. The index provides an index datastructure that includes a plurality of hash buckets. Each hash bucketincludes a collection of linked hash bucket units, and each hash bucketunit includes a set membership filter and a hash block. Each setmembership filter provides a mechanism for determining whether a setmembership key under consideration is associated with a correspondinghash bucket unit. Each hash block includes a plurality of hash entries.Each hash entry provides at least a partial key and an address value.Each partial key and each set membership key are derived from a full keyunder consideration, and each address value specifies a location of acorresponding key-value entry in the content store. The storeinteraction component is configured to store hash entries in aparticular collection of linked hash bucket units in a chronologicalorder based on time of creation, by storing each new hash entry in ahead hash bucket unit of the particular collection, and creating a newhead hash bucket unit when a previous head hash bucket unit cannotaccommodate a new hash entry. Each collection of linked hash bucketunits stores at least one of its most-recently-created hash blocks inthe in-memory index store, and at least some of its other hash blocks inthe secondary index store.

According to a second aspect, the key-value storage system isimplemented, at least in part, by one or more server computing devicesassociated with a network-accessible storage service.

According to a third aspect, the key-value storage system isimplemented, at least in part, by a user computing device.

According to a fourth aspect, the key-value storage system omits sortingfunctionality for sorting keys in the index.

According to a fifth aspect, each partial key and each set membershipkey are based on different respective portions of a full key underconsideration.

According to a sixth aspect, each set membership filter corresponds to abloom filter.

According to a seventh aspect, each hash bucket unit includes a pointerthat points to a location at which its corresponding hash block isstored in the secondary index store.

According to an eighth aspect, the store interaction component includesan insertion component that is configured to store a new key-value entryin the key-value storage system. The insertion component includes: logicconfigured to receive a full key and a value associated with the newkey-value entry; logic configured to store the full key and value in thecontent store, to provide the new key-value entry; logic configured tohash the full key to generate a hash bucket identifier; logic configuredto generate a partial key based on the full key; logic configured togenerate a set membership filter entry based on the full key; logicconfigured to identify a matching hash bucket based on the hash bucketidentifier; logic configured to determine whether an existing head hashblock, included within an existing head hash bucket unit in the matchinghash bucket, is full; logic configured to create a new head hash bucketunit having a new head hash block if the existing head hash bock isfull; logic configured to add the set membership filter entry to a setmembership filter of the new head hash bucket unit if the new head hashbucket unit has been created, else the existing head hash bucket unit;and logic configured to store a new hash entry in the new head hashblock if the new head hash block has been created, else the existinghead hash block, the new hash entry including at least the partial keyand an address value at which the new key-value entry is stored in thecontent store.

According to a ninth aspect, the store interaction component isconfigured to update a key-value entry by: storing a new version of thekey-value entry in the content store; and storing a new hash entrycorresponding to the new version of the key-value entry in the index,while preserving an old hash entry corresponding to a previous versionof the key-value entry. The index enables retrieval of either the newversion or the old version.

According to a tenth aspect, the store interaction component includes aquery component which is configured to locate a sought-after key-valueentry in the key-value storage system. The query component includes:logic configured to receive a full key associated with the sought-afterkey-value entry; logic configured to hash the full key to generate ahash bucket identifier; logic configured to generate a partial key basedon the full key; logic configured to generate a set membership filterentry based on the full key; logic configured to identify a matchinghash bucket based on the hash bucket identifier; logic configured toidentify a matching hash bucket unit by comparing the set membershipfilter entry to each set membership filter of the matching hash bucketuntil a match is found, if any, wherein the matching hash bucket unitincludes an associated matching hash block; logic configured todetermine whether the matching hash block is provided in the in-memoryindex store; and logic configured to retrieve the matching hash blockfrom the secondary index store and store the matching hash block in thein-memory index store if it is not already in the in-memory index store.

According to an eleventh aspect, the query component further includes:logic configured to identify a matching hash entry, if any, in thematching hash block, by comparing the partial key of the sought-afterkey-value entry with each hash entry in the matching hash block; andlogic configured to retrieve a key-value entry from the content storethat matches an address value specified by the matching hash entry, toprovide a retrieved key-value entry.

According to a twelfth aspect, the query component further includes:logic configured to determine whether a full key associated with theretrieved key-value entry matches a full key associated with thesought-after key-value entry; and logic configured to continue a searchwithin the index if the full key of the retrieved key-value entry doesnot match the full key associated with the sought-after key-value entry.

According to a thirteenth aspect, the store interaction componentincludes a relocation and eviction (R&E) component configured to updatethe index in response to operation of garbage collection functionality.The R&E component includes: logic configured to receive modificationinformation for a modified key-value entry, the modified key-value entrycorresponding to a particular key-value entry in the content store thathas been modified by the garbage collection functionality, wherein themodification information includes an old address value associated withthe particular key-value entry, a new address value associated with theparticular key-value entry, and a key associated with the particularkey-value entry; logic configured to find a matching hash entry in theindex based on the modification information; and logic configured toupdate the matching hash entry based on the modification information.

According to a fourteenth aspect, in a first case, the particularkey-value entry has been modified by the garbage collectionfunctionality to move the particular key-value entry from an oldlocation in the content store, associated with the old address value, toa new location in the content store, associated with the new addressvalue. In that situation, the above-referenced logic configured toupdate is configured to update the matching hash entry by changing anaddress value specified by the matching hash entry to correspond to thenew address value.

According to a fifteenth aspect, in a second case, the particularkey-value entry has been modified by the garbage collectionfunctionality to evict the particular key-value entry from the contentstore. In that situation, the new address value is set to an invalidvalue to indicate that the new address value is invalid, and theabove-referenced logic configured to update is configured to update thematching hash entry by changing an address value specified by thematching hash entry to correspond to the invalid value.

According to a sixteenth aspect, in the second case, theabove-referenced logic configured to update is further configured toupdate a partial key of the matching hash entry to correspond to aninvalid value.

According to a seventeenth aspect, each group of set membership filtersof a hash bucket has a configurable overall false positive probability,corresponding to a probability that a given set membership key matchesany one of the group of set membership filters, yet a corresponding hashbucket unit does not contain a sought-after hash entry. Further, eachparticular hash block has a configurable block collision probability,corresponding to a probability that a given partial key matches aparticular hash entry in the particular hash block, yet that particularhash entry does not identify a sought-after hash entry in the contentstore. Further, the key-value storage system exhibits a level ofperformance that depends at least on the configurable overall falsepositive probability and the configurable block collision probability.

According to an eighteenth aspect, a method is described for storing anew key-value entry in a key-value storage system. The method includes:storing the new key-value entry in a content store, the new key-valueentry providing a full key and an associated value; identifying amatching hash bucket associated with the full key, the matching hashbucket including a linked list of hash bucket units, each hash bucketunit including a set membership filter and a hash block for storing hashentries; and storing a new hash entry at a head hash block associatedwith a head hash bucket unit of the linked list. Each linked list ofhash bucket units stores at least one of its recently-created hashblocks in an in-memory index store and at least some of its other hashblocks in a secondary index store.

According to a nineteenth aspect, each hash entry in the above-describedmethod specifies a partial key associated with a full key of acorresponding key-value entry provided in the content store.

According to a twentieth aspect, a computer-readable storage medium isdescribed for storing computer-readable instructions, thecomputer-readable instructions, when executed by one or more processordevices, performing a method for retrieving information from a contentstore. The method includes: receiving a full key associated with asought-after key-value entry in the content store; generating a partialkey and a set membership filter entry based on the full key; identifyinga matching hash bucket associated with the full key, the matching hashbucket including a linked list of hash bucket units, each hash bucketunit including a set membership filter and a hash block for storing hashentries; identifying a matching hash bucket unit in the matching hashbucket based on the set membership filter entry, the matching hashbucket unit including a matching hash block; retrieving the matchinghash block from a secondary index store and storing the matching hashblock in an in-memory index store if the matching hash block is notalready in the in-memory index store; identifying a matching hash entry,if any, in the matching hash block based on the partial key; retrievinga key-value entry from the content store based on an address valuespecified by the matching hash entry, to provide a retrieved key-valueentry; and determining whether a full key associated with the retrievedkey-value entry matches a full key associated with the sought-afterkey-value entry.

A twenty-first aspect corresponds to any combination (e.g., anypermutation or subset) of the above-referenced first throughtwenty-first aspects.

A twenty-second aspect corresponds to any method counterpart, devicecounterpart, system counterpart, means-plus-function counterpart,computer-readable storage medium counterpart, data structurecounterpart, article of manufacture counterpart, graphical userinterface presentation counterpart, etc. associated with the firstthrough twenty-first aspects.

In closing, although the subject matter has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A key-value storage system, implemented by one ormore computing devices, comprising: a content store for storing aplurality of key-value entries, each key-value entry providing a fullkey and an associated value; an index including an in-memory index storeand a secondary index store; and a store interaction componentconfigured to interact with the content store using the index, the indexproviding an index data structure that includes: a plurality of hashbuckets, each hash bucket including a collection of linked hash bucketunits, each hash bucket unit including a set membership filter and ahash block, each set membership filter providing a mechanism fordetermining whether a set membership key under consideration isassociated with a corresponding hash bucket unit, each hash blockincluding a plurality of hash entries, each hash entry providing atleast a partial key and an address value, each partial key and each setmembership key being derived from a full key under consideration, andeach address value specifying a location of a corresponding key-valueentry in the content store, the store interaction component beingconfigured to store hash entries in a particular collection of linkedhash bucket units in a chronological order based on time of creation, bystoring each new hash entry in a head hash bucket unit of the particularcollection, and creating a new head hash bucket unit when a previoushead hash bucket unit cannot accommodate a new hash entry, and eachcollection of linked hash bucket units storing at least one of itsmost-recently-created hash blocks in the in-memory index store, and atleast some of its other hash blocks in the secondary index store.
 2. Thekey-value storage system of claim 1, wherein the key-value storagesystem is implemented, at least in part, by one or more server computingdevices associated with a network-accessible storage service.
 3. Thekey-value storage system of claim 1, wherein the key-value storagesystem is implemented, at least in part, by a user computing device. 4.The key-value storage system of claim 1, wherein the key-value storagesystem omits sorting functionality for sorting keys in the index.
 5. Thekey-value storage system of claim 1, wherein each partial key and eachset membership key are based on different respective portions of a fullkey under consideration.
 6. The key-value storage system of claim 1,wherein each set membership filter corresponds to a bloom filter.
 7. Thekey-value storage system of claim 1, wherein each hash bucket unitincludes a pointer that points to a location at which its correspondinghash block is stored in the secondary index store.
 8. The key-valuestorage system of claim 1, wherein the store interaction componentincludes an insertion component that is configured to store a newkey-value entry in the key-value storage system, the insertion componentcomprising: logic configured to receive a full key and a valueassociated with the new key-value entry; logic configured to store thefull key and value in the content store, to provide the new key-valueentry; logic configured to hash the full key to generate a hash bucketidentifier; logic configured to generate a partial key based on the fullkey; logic configured to generate a set membership filter entry based onthe full key; logic configured to identify a matching hash bucket basedon the hash bucket identifier; logic configured to determine whether anexisting head hash block, included within an existing head hash bucketunit in the matching hash bucket, is full; logic configured to create anew head hash bucket unit having a new head hash block if the existinghead hash bock is full; logic configured to add the set membershipfilter entry to a set membership filter of the new head hash bucket unitif the new head hash bucket unit has been created, else the existinghead hash bucket unit; and logic configured to store a new hash entry inthe new head hash block if the new head hash block has been created,else the existing head hash block, the new hash entry including at leastthe partial key and an address value at which the new key-value entry isstored in the content store.
 9. The key-value storage system of claim 1,wherein the store interaction component is configured to update akey-value entry by: storing a new version of the key-value entry in thecontent store; and storing a new hash entry corresponding to the newversion of the key-value entry in the index, while preserving an oldhash entry corresponding to a previous version of the key-value entry,the index enabling retrieval of either the new version or the oldversion.
 10. The key-value storage system of claim 1, wherein the storeinteraction component includes a query component which is configured tolocate a sought-after key-value entry in the key-value storage system,the query component comprising: logic configured to receive a full keyassociated with the sought-after key-value entry; logic configured tohash the full key to generate a hash bucket identifier; logic configuredto generate a partial key based on the full key; logic configured togenerate a set membership filter entry based on the full key; logicconfigured to identify a matching hash bucket based on the hash bucketidentifier; logic configured to identify a matching hash bucket unit bycomparing the set membership filter entry to each set membership filterof the matching hash bucket until a match is found, if any, wherein thematching hash bucket unit includes an associated matching hash block;logic configured to determine whether the matching hash block isprovided in the in-memory index store; and logic configured to retrievethe matching hash block from the secondary index store and store thematching hash block in the in-memory index store if it is not already inthe in-memory index store.
 11. The key-value storage system of claim 10,wherein the query component further comprises: logic configured toidentify a matching hash entry, if any, in the matching hash block, bycomparing the partial key of the sought-after key-value entry with eachhash entry in the matching hash block; and logic configured to retrievea key-value entry from the content store that matches an address valuespecified by the matching hash entry, to provide a retrieved key-valueentry.
 12. The key-value storage system of claim 11, wherein the querycomponent further comprises: logic configured to determine whether afull key associated with the retrieved key-value entry matches a fullkey associated with the sought-after key-value entry; and logicconfigured to continue a search within the index if the full key of theretrieved key-value entry does not match the full key associated withthe sought-after key-value entry.
 13. The key-value storage system ofclaim 1, wherein the store interaction component includes a relocationand eviction (R&E) component configured to update the index in responseto operation of garbage collection functionality, the R&E componentcomprising: logic configured to receive modification information for amodified key-value entry, the modified key-value entry corresponding toa particular key-value entry in the content store that has been modifiedby the garbage collection functionality; the modification informationincluding an old address value associated with the particular key-valueentry, a new address value associated with the particular key-valueentry, and a key associated with the particular key-value entry; logicconfigured to find a matching hash entry in the index based on themodification information; and logic configured to update the matchinghash entry based on the modification information.
 14. The key-valuestorage system of claim 13, wherein the particular key-value entry hasbeen modified by the garbage collection functionality to move theparticular key-value entry from an old location in the content store,associated with the old address value, to a new location in the contentstore, associated with the new address value, and wherein said logicconfigured to update is configured to update the matching hash entry bychanging an address value specified by the matching hash entry tocorrespond to the new address value.
 15. The key-value storage system ofclaim 13, wherein the particular key-value entry has been modified bythe garbage collection functionality to evict the particular key-valueentry from the content store, wherein the new address value is set to aninvalid value to indicate that the new address value is invalid, andwherein said logic configured to update is configured to update thematching hash entry by changing an address value specified by thematching hash entry to correspond to the invalid value.
 16. Thekey-value storage system of claim 15, wherein said logic configured toupdate is further configured to update a partial key of the matchinghash entry to correspond to an invalid value.
 17. The key-value storagesystem of claim 1, wherein: each group of set membership filters of ahash bucket has a configurable overall false positive probability,corresponding to a probability that a given set membership key matchesany one of the group of set membership filters, yet a corresponding hashbucket unit does not contain a sought-after hash entry, each particularhash block has a configurable block collision probability, correspondingto a probability that a given partial key matches a particular hashentry in the particular hash block, yet that particular hash entry doesnot identify a sought-after hash entry in the content store, and thekey-value storage system exhibiting a level of performance that dependsat least on the configurable overall false positive probability and theconfigurable block collision probability.
 18. A method for storing a newkey-value entry in a key-value storage system, comprising: storing thenew key-value entry in a content store, the new key-value entryproviding a full key and an associated value; identifying a matchinghash bucket associated with the full key, the matching hash bucketincluding a linked list of hash bucket units, each hash bucket unitincluding a set membership filter and a hash block for storing hashentries; and storing a new hash entry at a head hash block associatedwith a head hash bucket unit of the linked list, each linked list ofhash bucket units storing at least one of its recently-created hashblocks in an in-memory index store and at least some of its other hashblocks in a secondary index store.
 19. The method of claim 18, whereineach hash entry specifies a partial key associated with a full key of acorresponding key-value entry provided in the content store.
 20. Acomputer-readable storage medium for storing computer-readableinstructions, the computer-readable instructions, when executed by oneor more processor devices, performing a method for retrievinginformation from a content store that comprises: receiving a full keyassociated with a sought-after key-value entry in the content store;generating a partial key and a set membership filter entry based on thefull key; identifying a matching hash bucket associated with the fullkey, the matching hash bucket including a linked list of hash bucketunits, each hash bucket unit including a set membership filter and ahash block for storing hash entries; identifying a matching hash bucketunit in the matching hash bucket based on the set membership filterentry, the matching hash bucket unit including a matching hash block;retrieving the matching hash block from a secondary index store andstoring the matching hash block in an in-memory index store if thematching hash block is not already in the in-memory index store;identifying a matching hash entry, if any, in the matching hash blockbased on the partial key; retrieving a key-value entry from the contentstore based on an address value specified by the matching hash entry, toprovide a retrieved key-value entry; and determining whether a full keyassociated with the retrieved key-value entry matches a full keyassociated with the sought-after key-value entry.